Expected a local compiler error, but upon closer inspection jni is only used in a doc-example. Let's double-check that the CI catches this, though we'll then block on jni-rs/jni-rs#478.

It's not here yet, but I've prepared this PR for jni 0.22 (except possible Rust code changes) so that it should™ be as trivial as re-running the CI to get this merged, when that release happens.

Cool, I'd like to make a jni release soon but if I'm honest I'm not currently expecting it to happen before the 0.5 release of android-activity or winit 0.29.

Sure, just keep in mind that that's going to be a hassle for the community as the ndk won't be able to make such a breaking release for a while until winit does... We seem to be on a ± yearly breaking release schedule.

Surely the jni / jni-sys crates are only internal deps for the ndk crate so you should be ok to bump later?

I intentionally don't expose any jni types for android-activity so it wouldn't affect semver to bump.

Surely the jni / jni-sys crates are only internal deps for the ndk crate

This PR is marked as breaking for a reason 😉

Surely the jni / jni-sys crates are only internal deps for the ndk crate

This PR is marked as breaking for a reason 😉

where do the ndk / ndk-sys crates currently expose jni/jni-sys types? that doesn't sound good to me and maybe we can try to remove any exposure?

We seem to be on a ± yearly breaking release schedule

It could be nice if we could do more frequent releases and maybe not worry too much whether every release necessarily gets picked up by Winit.

where do the ndk / ndk-sys crates currently expose jni/jni-sys types? that doesn't sound good to me and maybe we can try to remove any exposure?

Only jni-sys types. Quite a few JNIEnv/jobjects in constructors. jni should only be used for a doc-example.

It could be nice if we could do more frequent releases and maybe not worry too much whether every release necessarily gets picked up by Winit.

We could, but it's annoying to have a mismatch between all crates that are so intertwined with windowing systems.

where do the ndk / ndk-sys crates currently expose jni/jni-sys types? that doesn't sound good to me and maybe we can try to remove any exposure?

Only jni-sys types. Quite a few JNIEnv/jobjects in constructors. jni should only be used for a doc-example.

I was pondering for a second whether we could do a 0.3.x release of the jni-sys crate with the semver trick. That's a tempting solution but really the JNIEnv type completely changed between jni-sys 0.3 and 0.4.

That's awkward in the sense that for 99% of things (and probably all the ndk crate usage) you only care about passing around an opaque pointer and probably don't ever dereference the JNIEnv pointer type.

@rib yeah we don't look at the innards of the type. Having a type-safe definition does help things not getting mixed up, though.